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METHOD OF CONTROLLING VEHICLE ACCESS 

ZIpcar _ . . 

Vehicle: Access, Board Computer, Transmission 

Figure 1 

The company will provide access to the cars with a proximity card based o^^^e Phillips M^^ 
rhin The card reader will be located behind the windscreen and be connected to the board 
compter Sd computer v«ll compare the ID of the card with the ID of the currently active 
reservation and will initiate to unlock the doors if they are the same. 

The board computer will contain an E2 memory chip and some rudimentary logic that will: 

" Compare the ID from the card reader with the ID of the active reservation and drive the door 

= CompS^tS PIN from the keyboard with the PIN from the active resen/atfon and un-interrupt 
the starter, 

■ Keep track of odometer reading, i„^i„atethQ 
. Perfonn a series of queries designed to extend a reservation from within the car. indicate the 
condition of the car. and send out a warning if customer will be late. 

The board computer will also have a user interface with keypad and display, (also see appendix 
1) 

We will perform the transmission of data from and to the board «»n^P"|f r«;''°"9*i.^°5|!!!-°^^^^^ 
Packet Radio Service (GPRS), which is currently under development by Omnipoint Technology. 
Zipcar will be one of the first companies to integrate this new digital service into an application. 
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Web-Based Administration 

Figure 2 



The Zipcar server will securely connect all software applications to the Internet. 
Readinas from the cars will be send to the service provider, from there, using Internet 
Protocol (IP) to the Internet and the database on the Zipcar server and vice versa (see 
appendix 2 for sent information). 
Clients will use the Internet to make their reservations. 

Billing will be done directly through debit cards or via email. . ^ . . *u 

New clients will apply directly on the web-site allowing for the data to be entered into the 
database electronically. 
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Reservation and billing Systems: 



Data transmitted wirelessly from car to server falls into the following types of data and is used as follows: 

Odometer reading and start/stop times as logged in/out by user: 

. Compiles the bill [components of billing overall are refundable security deposit; annual fee, 

houTy and per mile rates based on chosen plan. Also, rates for work-day rental, and 24-hr rentals 

supercede the hourly/mile rates.] - 
» updates user activity statements viewable by each member 
. Reports fov analysis [difference between actual use and reserved time, etc.] 

Notification that car is "OK/Not OK" [reporting state of cleanliness or car accident] 

. Triggers an email or phone call to person currently using the vehicle to followup on with details 
of the report so action can be taken. 

Request to extend reservation 

• Updates the reservation schedule 



ONLINE RESERVATION SYSTEM 

« Enables members to choose the city, car location, and time of reservation online from a schedule 
displaying car reservation status for the week. Users can change any parameters and see real-time 
display ofthe status of their request. 

. Meiiibers see status of upcoming reservations (ability to cancel or change this as well] and then 
activity statement for current and past months. 
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Appendix 1, Specifications for Vdiicle Systems 
Board Computer (BCT 



Proximity Card ; 
Reader sends ID # to 
board computer. 



Board computer stores reservation info 

[times and IDs) 

Board computer compares card and 
teservation ID and if ID diecks ou^ 
initiates opening of die door. Denies 
opening fee door ifID doesn't check < 



Sctbhi query: PIN # 



PIN # is entered: 
Goto screen with 4 < 



Server - Car Transmission 

Server sends info on reservations to 
the cars as they come in, whenever 
car is in it's E 



ff ardware requirement 



Internet connection for servCT. 
GPRS modem for car. 



Keypad and small screen, or touch 
screen, enter button; 



Screen witfi 4 options: 

(A) start session 

(B) reservation extension query 

(C) late status report 

(D) endsession 



(A) PIN belongs to reserved customer, 
board oonq)uter raiables ignition, 
grabs odometer reading and time 
and sends it to server. 



send data packet off to server 



m 



Car Status o Jl? 
'•yes" / 



salt "oJc" or "not oJc" oflFto server* 



Keypad with yes/no buttons or touch 
screen; 



Your reservation is x to y 
N minutes available after y 
Would you like to extend? -> "yes" 
"no" 



ditto 



if'W 



(B) Your resCTvation is X to y 
N minutes available after y 
How many additional minutes 
would you like? 
Enter in "30". "60", "90" 
Goto screen with 4 < 



Hardwire to odometer 



send data packet off to server 



1 options 



(C) Please type in the # of minutes you 
will be late.^ 

Goto screen with 4 options 



send data packet off to server^ 



some button that could signal infinity or 
touchscreen 



(D) End of session? 
"Yes" /"No" 



If "yes", disable ignition, grab 
odometer reading and time. 
Last query: car status o Jc? 

^^" / _ 



send data packet with odometer 
reading and time to server 



If "no" leave everything as is and 
goto screen with 4 options. 



^ card has a unique #, all cards open all doors card unidentifiable— no logo 
^ When the car is reserved it opens for the customer who has the reservation only. 
It also opens to any ZipCar user if the car is currently not reserved. 
^ Triggers email to customer vidth complaints-form. 
^ "x" # of minutes, or "infinite" # of minutes -> accident or break-down. 
^ Triggers phone call to next customer. Triggers find a replacement car for location. 
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Appendix 2 

Zipcar Car-server Message Contents 

1 .Add/delete reservation message: when the server sends the reservation information to the car, 
it will send the following: 

type=add or delete reservation 

user ID 

PIN 

pickup date/time 
return dateAime 
reservation ID 
vehlclelD 
current dateAinne 

2. Usage message: when the car sends usage records back to the server, it will send the 
following: 

type=pickup or return 

userlD 

dateAime 

mileage 

status code(s) 

reservation ID 

vehiclelD 

3. Reservation extension request message: when the user requests an extension to the 
reservation, the car will send the following: 

type=extend reservation 

userlD 

dateAime 

reservationID 

vehiclelD 

extension duration 

4. Reservation extension acknowledgement message: the server will respond to the Reservation 
extension request message with a message containing the 

following: 

type=acknowledge reservation extension 

ok/denied flag 

reservationID 

vehiclelD 

current dateAime 

userlD 

new return dateAime 

5. Power up message: when the car first recovers from a power failure, it will send the following: 

type=request for all pending reservations 
vehiclelD 

This will trigger a flood of Add Reservation messages back from the server. 
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MIFARE® - The Architecture Platform for Contactless 
smart cards 



With close to 50,000 read/write devices and 10 million 
IMIFARE® chips in use In more than fourty operational 
installations world-wide, Philips Semiconductors Is 
leading the Smart Card Industry into the contactless era. 

In the late 80s the need for a fast, easy to use and secure 
smart card was concentrated in Public Transport. The idea 
behind the concept, however, was to have one single card to 
be used for several applications at the same time. The result 
of all these efforts was the MIFARE® Technology, which in 
comparison to contact technology was developed at a 
breathtaking pace. 

Keeping in mind the fundamental requirements to the 
system, it was considered very important to create an 
upward compatible MIFARE® Hardware Architecture. This 
continuously expanding modular architecture covers 
products for any service provider wishing to apply 
contactless smart card technology to their needs. 

Today the MIFARE® Architecture Platform comprises a 
variety of compatible reader modules suitable for multi- 
facetted target applications as well as different types of 
MIFARE® card ICs. In order to keep the leading position in 
contactless smart card technology further developments are, 
of course, under way. 

AfllFARE® Card iCs 

The different available card ICs are tailored to allow the 
implementation of comprehensive smart card systems based 
on different types of cards which are all compatible with the 
MIFARE® reader infrastructure. The three MIFARE® Card 
IC types ranked by their functionality are: 

® MBFARE® LIGHT designed for single application cards 



http://www.semiconductors.com/publications/content/file_1 1 5.html 2/1 6/00 



Philips Semiconductors ■Publications; MIFARE® - The A-^fiitectur.. Page 2 of 3 

such as electronic 10-trlp tickets in public transport or 
phone cards. This optimized small memory product 
targeted at high volume, cost sensitive applications is 
also an efficient, fast and secure substitute for 
magnetic stripe cards currently used in applications like 
road toll, energy metering and similar 

• The standard contactless MIFARBD1 S50 used for 
complex multifunctional types of applications. With its 
significantly larger memory new functions and/or 
applications can be easily added to the card. 

• MIFARE® PLUS, the CombI Card IC developed by 
Phillps/Mikron, makes use of both, the contact and the 
contactless infrastructure. 

The next generation of Philips Semiconductors' MIFARE® 
based contactless controller ICs is currently under 
development: 



MIFARE® PRO. 

This generation will comprise card ICs with a processor 
being able to handle both Interfaces, contact and 
contactless, which will further increase user convenience, 
flexibility and security. 

MIFARE® Read/Write Modules 

The variety of read/write modules offer different read/write 
distances and depending on the specific needs can either be 
ready to plug in or require more complex integration. 

The MIFARE® product range for read/write modules 
Includes: 



The MIFARE® Core Module with a read/write distance 
of typically 100 mm is dedicated to applications 
requiring a high throughput of secure transactions in a 
minimum amount of time. Target applications are gate 
controllers in metro stations, bus terminals, EFT POS 
terminals or even PCs. 

The MIFARE® Serial Reader Proximity with a typical 
operating distance of 65 mm Is the counterpart to the 
MIFARE® Core Module offering several serial 
interfaces for the communication with the host system. 
It is suited for terminals using control LEDs, switches or 
buttons for the transaction with a contactless card. 
The MIFARE® Micro Module with a typical read/write 
distance of 25 mm can be used for small, compact 
readers, handheld devices, slot or surface readers. 



http://www.semiconductors.com/publications/content/fileJ 1 5.html 
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Typical high volume applications are on-board units for 
non-stop road toll, metering units or public payphones. 
• The MIFARE® Serial Reader Short Range with a 
typical operating distance of 25 mm is based on the 
MIFARE® Micro Module and features an RS232 serial 
interface. For system integration of this reader into a 
specific application only basic knowledge of the 
MIFARE® System is required. 

Based on the wide range of products already available and 
further innovations to be added to the MIFARE® Hardware 
Architecture, Philips Semiconductors is fully committed to 
maintain the Architecture Platform on the basis of MIFARE® 
beyond the year 2000. 
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GPRS Strategies: 

Planning a Successful Adoption 



Introduction 

With General Packet Radio Service (GPRS), an important step toArard 
third-generation services, GSM operators can offer cost-effective, 
^ e0fiiSSttvi^^t rates up to 115 Kbits per second. GPRS is the 
networis technology choice for the evolution of both GSM and US 
standard IS- 136 networks. GPRS coupled with Enhanced Data rates 
for Global Evolution (EDGE) will enable GSM and IS- 136 operators 
to offer wireless multimedia IP-based services and applications at 
speeds up to 384 Idiit/s. GPRS was designed to be added with 
minimal cost and disruption, but as with any new technology, a 
successful transition starts with careful plannii^ and a realistic 
assessment of the task. 

This paper offers a perspective on positionii^ GPRS relative to 
other advanced GSM offerings, describes die netwods modifications 
that GPRS requires, and explores the business and technology choices 
involved in a successful GPRS adoption. 

Positioning GPRS for Customers 

GPRS is not the only new technology available for boosting GSM data 
rates, of course. High Speed Circuit Switched Data (HSCSD) was 
designed as a higher-speed alternative to standard GSM service and 
can offer data transfer speeds up to 57.6 Kbps. For the operator, 
HSCSD is easy to implement since it consists primarily of software 
upgrades with no backhaul modifications. For the end user, HSCSD 
helps enable such data-intensive applications as Web browsing, real- 
time services, and large file transfers. 

While GPRS has the potential to deliver higher data rates as 
well, in a realistic assessment, actual rates in die near term are likely to 
be significandy lower than 115 Kbps. The real strength of GPRS is the 
ability to offer cost-effective, continuous connectivity. GPRS is 
optimized for "bursty* transmissions, ^ietoere useis Would life to be 
cormectedftdl time biit won't generate enoi^h trafflfe to justify 
dedicated channels. Because packet technology doesn't dedicate a 
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GPRS Strategies: 

Planning a Successful Adoption 



circuit for each connection, operators can offer users the opportunity 
to stay online without incurring exorbitant airtinae charges. 

Given the complementary nature of the two services, the ideal 
situation will be to implement both technologies and promote them to 
customers based on applicatiorL 
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GPRS AND Network Operators' Key 
Success Factors 

The abiUty to grow into the future ao doubt played a key part in every 
operator's decision to adopt GSM. As with every planned 
enhancement to GSM, GPRS supports the operator's key success 
factoid in the highly competitive wireless market: 

© Time to market As all operators know all too well, the market 
for voice and data services is becoming increasingly competitive 
and new entrants are able to establish themselves quickly By 
brir^irg advanced services such as GPRS online as quicUy as 
possible, GSM operators can continue to exploit GSM's inherent 
advant^es for handling digital data. 

0 Open platfotm for continued upgtadability . Similarly, GSM's 
philosophy of designing for the future with an open platform will 
help network operators and service providers respond quicHy to 
new mariset demands. While GPRS does require a number of 
charges to the GSM network, it offers a fundamentally new kind 
of service while leveraging the investments already made in the 
basic network 

© More users per available spectrum New GSM services utilize 
the spectrum and network resources more efficiendy, resulting in 
more subscribers and higher revenues relative to cost. GPRS, for 
instance, uses network resources so efficiendy operators can offer 
continuous cormectivity at a fraction of the cost of a full-time 
circuit-switched connection. 
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A Realistic Look at GPRS Implementation 



Omnipoint Technologies has been designing and integiatii^ Avireless 
voice and data solutions for more dian a decade, includii^ some of the 
pioneering installations of GSM in North America. As both ecpiipment 
designers and consulting engineers, \ve work closely with a variety of 
GSM technology leaders around the world to offer sohitions ranging 
from industrial telemetry to enhanced location services. Our sister 
company, Omnipoint Gommunicauon Services, is one of the most 
experienced GSM operators in Nordi America. Moreover, we 
continue to play an active role in the development of GSM standards, 

including GPRS. 

This extensive hands-on experience with GSM technologies has 
provided a solid education in the realities of networis: buildouts and 
upgrades. GPRS and odier emerging technologies offer exciting 
opportunities for equipment manufacturers and operators alike, but we 
believe a realistic assessment of the challenges inherent in any 
technology upgrade will help all parties involved reach tiieir business 
objectives more easily. 

How GPRS Changes an Existing Network 

Adding GPRS to an established GSM network involves the addition of 
two new support nodes and a number of other hardware and software 
changes throughout the network GPRS also introduces three new 
network operation modes and support for three classes of mobile 
terminals. 

New Support Nodes 

The implementation of GPRS will introduce two new nodes required 
for handling packet traffic: 

® The serving GPRS support node (SGSN) is connected directly 
to the base station subsystem (BSS) via the Gb interface. It 
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controls access, tracks user locations, and performs various 
security functions. 

The gateway GPRS support node (GGSN) serves as the 
interconnection point for packet data networks. It is connected to 
the SGSN via the Gn interface, an IP backbone. The GGSN's 
main functions are to set up and authenticate communication with 
external packet networks and to route and tunnel packets to and 
from die SGSN. 




Both of these new nodes generate billing information diat identifies 
which external packet network was used, the amount of data 
transferred, the quality of service (QoS) offered, and the duration of 
the coimection. Figure 1 shows how the new nodes fit into the GSM 
architecture. 



Other Hardware and Software 
Changes 

The base station controller (BSQ 
will also require hardware and 
software upgrades, including a 
packet control unit (PCU) to 
mans^e the transfer of packet 
data between mobile terminals 
and the SGSN. In addition to 
these hardware changes, GPRS 
requires a nxmiber of software 
charges throughout the network 
For instance, the home location 
register (HLf^, the mobile 
switching center (MSQ and the 
visitor location register (VU^ 
need to be upgraded to support 
GPRS services and to manage 
the new classes of mobile 
terminals. 
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New Network Operahon Modes 

The GPRS/GSM network can provide coordination of paging for 
circuit-switched (CS) and packet-switched services/Hie GPRS 
standard defines three network operation modes based on the extent 
of the coordination offered: 

9 Network opetatioii mode I: The network sends a CS paging 
message for a GPRS-attached mobile subscriber (MS), either on 
the same charmel as the GPRS paging channel or on a GPRS 
traffic charmel. The MS needs to monitor only one p^ir^ charmel, 
and it receives CS p^ing messages on the packet data charmel 
after that channel has been assigned. 

0 Netwodc opetation mode 11: The network sends a CS p^i&xig 
message for a GPRS-attached MS on the common paging charmel, 
and this channel is also used for GPRS p^ing. The MS needs to 
monitor only the conmion paging charmel, but CS pagir^ 
continues on this paging charmel even if die MS has been assigned 
a packet data channel. 

© Network operation mode III: The network sends a CS paging 
message for a GPRS-attached MS on the common paging charmel 
and sends a GPRS paging mess^e on eidier the GPRS paging 
channel (if allocated in the celS) or on the common p^ing charmel. 
Therefore, an MS who wants to receive pages for both circuit- 
switched and packet-switched services needs to monitor both 
paging channels if the packet paging channel is allocated m the cell. 
No paging coordination is performed by the network. 

The implications of these new modes will be more readily apparent 
later in the paper, in the discussion on cormecting to the GSM 
network subsystem (NSS). 
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New Classes of Mobile Tbwinals 

The GPRS standard also defines three new classes of mobile terminals, 
based on tlieir ability to handle circuit-switched and packet-switched 
data: 

• Qass A terminals support simultaneous circuit-switched and 
packet-switched data traffic. 

o Class B temiinals support either circuit-switched or packet- 
switched data traffic but can operate in only one mode at a given 
time. 

0 Class C temiinals operate exclusively as packet-switched 
terminals. 

With these additions in mind, we can now take a closer look at some 
of the key technical challenges operators are likely to face in a GPRS 
upgrade. 
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Technical Challenges in Implementing GPRS 

As network operators upgrade to HSCSD, GPRS and on to third- 
generation capabilities, it's vital to understand the technological 
challenges these upgrades present and the impact they may have on 
quality of service, time to market, and overall conyetitiveness. This 
section steps through four keysets of decisions: 

1 . Gonnectic^ to the GSM base station subsystem 

2. Gonnecting to the GSM network subsystem 

3 . Gonnecting to other pxiblic kind mobile networks 

4 . Gonnecting to external data networks 

Most of the technical questions regarding these connections can be 
^ anticipated and resolved during the planning stage. However, diere are 

a few issues that may need refinement as the industry builds 
expenence with GPRS. 

Connecting to the GSM Base Station Subsystem 

The Gb interface is the connection between the new SGSN node and 
the existing GSM BSS, as shown previously ia Figure 1. Frame relay 
provides the link layer mechanism for this interface. During initial roll 
out, when GPRS traffic is limited, multiplexing the Gb interface with 
the A interface over a Tl is a likely scenario. In most networks, an 
SGSN can be direcdy cormected to a BSC This topology fits the 
multiplexing idea nicely, since the SGSN and the MSG/VLR will most 
likely be colocated in initial GPRS implemenutions. 

As GPRS traffic increases, however, there are likely to be several 
scenarios in which it makes sense to centralize the SGSN equipment 
away from existing circuit-switched NSS equipment and to use a 
public frame relay network between die BSS and the GPRS NSS. For 
instance, the packet-switch portion of the GSM service can be offered 
by a third-party that specializes in advanced data services. Preparing 
for such possible migration scenarios and analyzing their implications, 
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both financial and technical, should be a key step in any GPRS 
plannii]^ effort. 

An even more critical issvie is the tise of flow control within the 
BSS GPRS protocol (BSSGP). Unfortunately, the downlink flow 
control was something of an afterthought and was detailed in later 
revisions of the GSM 08.18 standard Experience will tell if die 
implementation of the recommended leaiky bucket algorithm in the 
SGSN will be enot^ to differentiate between different delay classes, 
Another major concem is whether there are enough configuration 
parameters to control the method of traffic shaping widiin the SGSN. 
Again, this will be resolved with operational e^erience, and both 
issues will demand more attention when BSS and GPRS NSS 
eqmpment from different vendors are intercoimected. 

Connecting to the GSM Network Subsystem 

The GPRS NSS is connected to die existing GSM NSS via a number 
of new interfaces. The Gs interface connects the SGSN to die 
MSC/VLR, and the Gd interface connects the SGSN and the SMS- 
GMSC The Gr and Gc interfaces connect the SGSN and the GGSN 
to the HLR, respectively. Operators might want to consider the option 
of eliminating the Gc interface completely and using die SGSN as the 
relay between the GGSN and the HLR. This will remove the 
requirement of an SS7 interface in the GGSN and let operators 
construct the GGSN as a pure IP gateway. (The SGSN, however, is 
GPRS-specific equipment that by definition has to contain a number 
of specialized GPRS functions.) 

Among these various interfaces with the GSM NSS, Gs is the 
most significant. When diis interface is available, the GPRS network 
mode I will be available and usir^ class B mobiles will be a trivial 
matter. However, the Gs interface is optional when the network mode 
is n or III, so paging coorxiination will be unavailable. This may force 
restrictions on the downlink data path for die mobile— feeping in 
mind diat class B mobiles will likely constitute a s^dficant portion of 
the initial terminal market thanks to better voice-data integration. 
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Connecting to Othhi GPRS PLMMs 

The inter-PLMN network will be constructed via connections amoi^ 
border gateways (BGs) belonging to different PLMNs. Operators can 
choose from four different PLMN interconnection strategies: 

1. Direcdyconnect BGs of different PL^INs. 

2 . Interconnect the BGs at a conunon network service point (NSP) ^ 
owned and operated by the GSM Alliance. 

3 . Interconnect the BGs over a virtual private network (VPr^ using a 
backbone provider's link layer network 

4. Interconnect the BGs over a VPN using the Internet. 

Strategy 1: Direct B&-BG Coimections 

With strategy 1, the BGs need to be connected via PPP or frame relay 
over a Tl connection. The Tl can be used non-channelized, 
channelized into 56 Kbps channels, or in fractional mode. Support for 
single-link PPP is required, and support for multi-link PPP is desirable 
as well. Frame relay must support permanent virtual circuits (PVGs), 
with optional support for switched virtual circuits (SVGs). In addition, 
the frame relay unit must be able to act both in data terminating 
equipment pTE) and data communications equipment pGE) modes. 

The biggest advantage of this strategy is the opportunity for 
progressive build-up of the interconnection network The primary 
disadvantage will appear when a large number of PLMNs are 
connected in a fuU mesh, creating a prohibitive number of direct Hnks. 

Strategy 2: Network Service Point 

With strategy 2, BGs are connected via 100BaseT Edieraet; support 
for Gigabit Ethernet is highly desirable as well. The interconnection 
between the GGSNs and the BG will most likely be point-to-point. 
Gonsequendy, the BGs must support the interfaces described for 
strategy 1. 

The biggest advantage of this strategy is the chance to share at 
least some of the costs involved in building an inter-PLMN network 
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When an entity such as GSM Alliance operates the NSP, the quality 
can also be assured. On the other hand, building a full-fledged NSP 
when there are only a few early adopters of the technology may be 
unattractive for the PLMNs involved. Another potential problem 
could be the need for building multiple NSPs driven by geography or 
fault- tolerancy requirements. 

Strategy 3: VPN via the Backbone Provider's link Layet 

With strategy 3, BGs are connected to the backbone provider's 
network via frame relay over Tl or ATM over SONET. The Tl can 
be used non-charmelized, channelized into 56 Kbps chatmels, or in 
fractional mode. The frame relay implementation must support PVQ 
(support for SVGs is ^ain optional, and the frame relay unit must be 
able to act in DTE mode. The Internet Protocol (IP) should be carried 
over AAL5 as defined in RFG2225 or as defined in RFC 1577. ATM 
PVC support is also required, although SVC support is optional. The 
ATM interface should be configured as UNI DTE. The physical layer 
must be SONET STC3c with either an electrical, coaxial cable 
interface or a single or multimode fiber-optic interface. 

The biggest advantage of this strategy is the ability to offload the 
difficulties of interconnecting and operating the inter-PLMN network 
Since the backbone provider is responsible for each PLMISPs 
intercormectivity, there is no need for an inter-PLMN operator entity 
dedicated to the operation of such a netwoik Most of these services 
will be provided by the backbone provider. Adisadvant^e of this 
strategy is the potential cost, particulariy if the backbone provider 
perceives this VPN as a service beyond the imderlying link layer 
connectivity, in which case PIMNs maybe required to pay a 
significant premium for this service. Another potential problem could 
be synchronizing the growth of the inter-PLMN VPN with the plans 
of the backbone provider. 
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Strategy 4: VPN ^da the Internet 

With strategy 4, a BG is connected to the Internet through one or 
more ISPs. These one-to-one connections can be over point-to-point 
links, over an NSP or over a backbone provider's link layer network 
Depending on this interconnection strategy, one of the transport 
methods described above can be selected (Note, however, diat this 
strategy makes the nse of the security protocol IPSec among BGs 
mandatory, whereas it maybe considered optional for other strategies.) 

The biggest advantage of this strategy is the ability to build 
various topologies easily. Each BG can be connected to multiple ISPs, 
crcating multiple routes between each BG P^'^^-^J^^^J^ ' 

disadvantage is the lack of QoS guarantees in today's Internet. Even 
though connections to multiple ISPs provide alternate paths, daere is 
always the chance of significant degradation in the end-to-end QoS. 

Connecting to External Data Networks 

There are a number of interconnectivity challeiiges when considering 
the links between GPRS PLMNs and an external network such as an 
ISP or a corporate network An operator will face different technical 
issues depending on which of two basic business models is chosen: 
o Model A: Wifeless access providet. The GPRS PLMN operator 
takes a passive stance toward managing the IP address space for its 
subscribers. In this model, the addresses are allocated by the 
cormected ISPs and corporate networks. 

© Model B: Integrated voice/data provider. The GPRS PLMN 
operator actively manages the IP address space for its subscribers. 
In this model, the static and dynamic addresses are allocated by the 
PIMN. 

A third option would be to combine both business models, in which 
case an operator needs to consider both sets of technical issues. 
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Business Model A: mrdess Access Ptovider 
This scenario results in the PLMN being a pure access network used 
to extend the reach of an ISP or a corporate network (Figure 2). In 
this scenario, IP addresses are allocated by the subscribed ISP or the 
corporate network In case of roaming, the subscriber can use a 
GGSN in the visited PIMN provided that diere is connectivity 
between the visited PLMN and the ISP. If this can be guaranteed, 
there is no need for the Gp interface. However, we don't anticipate 
that this connectivity will always be available. Therefore, 
interconnectivity between PLMNs via the Gp interface is still 
necessary. 

This business model has the advant^e of relieving die PLMN 
operator from the bmdens of providing total Internet access service. 

The obvious disadvantage is 
not beir^ able to provide 
integrated services. 



Connecting with ISPs 
In this wireless access model, 
the PLMN becomes an 
extension of external networks. 
Address space is managed by 
the ISP, who also administers 
the addresses provided via 
dynamic addressing. In this 
model, the interconnectivity is 
based on pure tunneling and 
one-to-one coimections 
between the PLMN and 
connected ISPs. Roaming will 
require the use of the home 
GGSN if the ISP does not 
have direct connectivity to the 
visited PLMN. 
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Connecting to Corporate Networks 

Connectdng to corporate networks with this business model will 
require dedicated connections, A link layer VPN can be built over die 
GPRS and frame relay or ATM connections between the subscriber 
and the corporate network. 

Connecting PLMNs for MS-MS TraSSc 

As with ISPs and corporate networis, the model of interconnection 
among GPRS PLMNs for MS-MS traffic depends on die business 
model In the wireless access provider model, there is no need for 
interconnectivity between die PLMNs for MS-MS traffic, since routing 
is handled by the existing peering and client-provider relationships 
among ISPs and/or corporate networks. In fact, this model doesn't 
require any special treatment at all for MS-MS traffic. 

Business Model B: Integrated Voice/Internet Providet 

This business model creates a "wireless ISP" ^ose subscribers can 
obtain their IP addresses from dieir home GGSN figure 3). The 
biggest advant^e of this model is its strategic implications, since the 
PLMN operator can provide integrated voice and Internet services. 

In order to provide ubiquitous coverage for roaming 
subscribers, interconnectivity between PLMNs via die Gp interface is 
a necessity. A roaming MS is always required to use its home GGSN. 
This simplifies security provisions, but the obvious disadvantage is the 
use of the home GGSN even when communicatii^ with IP hosts 
nearby. This can be a significant issue when global roaming is 
considered. (Independent of roaming capability, PLMNs will be 
connected to the global Internet or corporate intranets through their 
BGs. A PLMN can also be deployed for pure local coverage, which 
does not require any intercormectivity with other PIMNs.) 
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Cotmecdng with ISPs 
With this business model, in 
which the GPRS PLMN 
operator is acting as an 
integrated voice/Internet 
provider, the PLMN and other 
ISPs arc libely to have client- 
provider relationships or peering 
rclationships. The client- 
provider relationship is more 
likely during the early stages of 
PlivD^f deploytnent, considering 
the limited stibscriber base. 
However, with an increasing 
number of subscribers and 
resulting network traffic, peerir^ 
relationships arc more 
appropriate. In this case, the 
PLMN can be cormected to a 
number of ISPs at a regional 



exchange point or can be dircctly cormeaed via one-to-one 
connections. The PLMN functions as a regular autonomous system 
(AS), administering its own address space and interconnectivity. The 
typical inter-AS routing policy tools, such as Border Gateway Protocol 
^GP), will be vised to manage the interconnectivity. 

Coxmecdngwitb Corporate Networks 

Intercormecrivity with corporate network can be accomplished via IP- 
level tunneling- In this model, a subscriber-initiated turmeling protocol 
such as PPTP virtual dial-up or pure IPSec tunneling can be adequate 
for corporate connectivity. There is no need for one-to-one 
connection between the corporate network and the PLMN. 
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Connecting PLMNs £br M&MS tra£Bc 

As mentioned above, when the PLMNs operate as wireless ISPs, they 
can establish client-provider or peering relationships. These ^vireless 
ISPs can exchange dieir traffic at one or more jointly established 
NSPs. Another alternative may be to contract a bacld>one provider, 
which forms the next level of hierarchy. In eidier case, we anticipate 
that MS-MS traffic will eventually become a significant portion of the 
overall GPRS traffic, provided that enabling applications such as 
advanced messj^ii^ are available. 

When the wireless ISPs get into peerii^ relationships, the issue 
of accounting will become critical, since the operators will have to 
^ree on a cost compensation model. No-fee, flat-fee or fees based on 
trunk capacity are the common models on the Internet today. In a 
pure best-effort network, these models can be readily adopted by the 
PLMN operators. On the other hand, when the quality of service 
demanded by the subscriber becomes a critical service issue, more 
involved cost compensation models, such as packet cost accounting 
and TCP session accounting, maybe necessary. 

Interconnecting to a QoS-Enabled Internet 

In today's best-effort only Internet, the quality of service provided to 
the subscriber is not under the provider's total control Since packets 
traveling to and from the subscriber travel through a number of 
domains beyond the provider's reach, GPRS PLMN operators will not 
be able to increase the subscriber's delivered QoS byprovidir^ 
significandy higher QoS in their own networks. Therefore, the 
interconnectivity model selected by the wireless ISP will be totally 
dependent on the price. 

When QoS is enabled across the Internet, the wireless ISP will 
be able to negotiate service contracts based on QoS. Service level 
agreements (SLAs) executed between the wireless ISP and its 
providers and/or peer domains will be legally binding documents, 
allowing the operator to engineer the network and intercormections to 
be able to deliver the QoS levels expected by subscribers. 
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The QoS-enabkd Internet will become a reality only when the 
enabling technologies become prevalent. Today there are a number of 
competing technologies, such as link layer ^proaches and the 
integrated services and differentiated services frameworks. The link 
layer approaches based on the inherent abilities of frame relay and 
ATM cannot be intemetworked easily with IP4evel traffic 
classification and scheduling mechanisms. The integrated services 
framework is based on the use of reservation and keeping soft-state 
within the network Unfortunately, this approach is not scalable 
enough to embrace the vast number of active sessions on the Internet. 
The differentiated services framework is scalable, thanks to the coarse 
p quantization of QoS expected. However, since this framework lacks 

=fl the mechanisms to negotiate the end-to-end service, delivered QoS 

will still depend on the level of engineering quality in domains other 
than die PLMN. 

Given the uncertainties, it is clear that the GPRS PIMN must 
be versatile enough to let the operator react wherever QoS technology 
goes. This is crucial to keep in mind when making decisions about the 
capabilities of the NSS and the BSS. 

Stepping into the Future 

GPRS is a significant milestone in the evolution of GSM, and it 
presents a great opportunity for operators to esqpand service offerings 
and stay ahead of competing networks. An agile implementation that 
considers all the possible developments in market demand and 
technology adoption will provide important benefits for both the 
operator and the end user. 

With our many years of experience in wireless network design 
and implementation, Omnipoint Technologies is available to assist 
GSM North American operators with the move to GPRS and other 
advanced services. We can provide independent advice on business 
models, nenvork engineering, performance improvements and other 
key factors that affect the long-term success of our clients. 
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GLOSSARY 



AAL 

AS 

ATM 

BG 

BGP 

BSC 

BSS 



BSSGP 
CS 



ATM Adaptation Layer 
Autonomous System 
Asynchronous Transfer Mode 
Border Gateway 
Border Gateway Protocol 
Base Sution Controller 
Base Station Subsystem 
BSS GPRS Protocol 
Qrcuit Switched 



DCE Data Orcuit-tenninatii^ Equipment 

DTE Data Terminal Equipment 

EDGE Enhanceed Data rates for Global Evolution 

GGSN Gateway GPRS Support Node 

GMSC Gateway Mobile Switching Center 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

GTP GPRS Tunnelii^ Protocol 

HLR Home Location Register 

HSCSD Hgh Speed Circuit Switched Data 

IP Internet Protocol 

IPSec IP Security 

ISP Internet Service Provider 

MS Mobile Station 

MSG Mobile Switching Center 

NSP Network Service Point 

NSS Network Switching Subsystem 

PLMN Public Land Mobile Network 

PPP Point-to-Point Protocol 

PPTP Point-to Point Turmeling Protocol 

PVC Permanent Virtual Circuit 

QoS Quality of Service 

RFC Request For Comment 

SGSN Serving GPRS Support Node 
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SLA Service Level Agreement 

SMS Short Message Service 
SONET Synchronoiis Optical NETwork 

SS7 Signaling System no. 7 

SVC Switched Virtual Grcuit 

TCP Transmission Control Protocol 

UM User Network Interface 

VLR Visiting Location Register 

VPN Virtual Private Network 
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